home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 4893 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.9 KB  |  134 lines
  1. Newsgroups: comp.sys.amiga.misc
  2. Path: leeds.ac.uk!news
  3. From: csxjmo@scs.leeds.ac.uk (J M Oldak)
  4. Subject: Re: Acorn RiscPC --- a thought?
  5. Message-ID: <1996Feb12.152844.28437@leeds.ac.uk>
  6. NNTP-Posting-Host: csgi47.leeds.ac.uk
  7. Organization: The University of Leeds, School of Computer Studies
  8. Date: Mon, 12 Feb 1996 15:28:44 +0000 (GMT)
  9. References: <1996Feb5.164323.465@rmcs.cranfield.ac.uk>
  10.     <4f5qvt$1hm@vulture.dmem.strath.ac.uk>
  11.     <1996Feb8.124744.14853@leeds.ac.uk>
  12.     <4fdglm$b8s@vulture.dmem.strath.ac.uk>
  13.  
  14. Neil Brendan Clark writes:
  15.  
  16. |> J M Oldak (That's me) wrote:
  17. |> >
  18. |> >There is nothing wrong with cooperative multitasking, when implemented
  19. |> >properly. 
  20. |> 
  21. |> You are wrong. With cooperative multitasking, the current program will soak
  22. |> up all the CPU time it can get until it voluntarily relinquishes the CPU,
  23. |> either explicitly with a "yield()" type call or by calling certain system
  24. |> functions. This has several implications; a runaway task can hog the entire
  25. |> computer, requiring a reboot. It is more difficult to program well, as 
  26. |> you have to explicitly decide when to give up the CPU. Busy tasks have
  27. |> a hard time of it too; imagine you decide to, say yield every 1000 iterations
  28. |> of some loop. On a slow machine, this may be fine in terms of user response,
  29. |> but on a faster machine, you'll be wasting CPU time by yielding too often.
  30. |> So the programmer sets up timing mechanisms to help? Fine. More CPU time,
  31. |> more hassle, more bugs. Any notion of the system of being remotely real-time
  32. |> is effectively quashed.
  33.  
  34. On the plus side - Co-operative multitasking means that the programmer has to
  35. be aware of the efficiency of the program. This means that the program can use
  36. little or no processor time if it isn't doing much. For example, a desktop
  37. clock only has to bother the OS every second, the rest of the time it can use
  38. no time at all. Furthermore, there are times when single tasking something is
  39. an advantage. If you are, say, viewing an MPEG (possibly a bad example...),
  40. why not let the thing single task? There are times when you want as fast a
  41. response as possible...
  42.  
  43. |> >whereas Risc OS (Acorn's operating system) allowes all
  44. |> >tasks to have processor time. 
  45. |> 
  46. |> How does it do this? Does it force a task off the CPU at certain time 
  47. |> intervals?
  48.  
  49. No, it just let's all tasks that want processor time have it. Win 3.1 (and Win
  50. 95 with old apps) does not.
  51.  
  52. |> >This means I can run a DTP program, 
  53. |> 
  54. |> Shouldn't need any CPU unless it is being used at the time...
  55.  
  56. Exactly, with a pre-emptive system it would be getting some!
  57.  
  58. |> >command shell, 
  59. |> 
  60. |> See above.
  61.  
  62. See above...
  63.  
  64. |> >desktop utilities, 
  65. |> 
  66. |> See above.
  67.  
  68. ditto...
  69.  
  70. |> >be printing in the background, 
  71. |> 
  72. |> And quite rightly too! This is not difficult, as printing generally involves
  73. |> little CPU time, unless you are interpreting PostScript with the CPU. The
  74. |> printer goes much slower than the CPU after all. OK, you have this one.
  75.  
  76. gee, thanks!
  77.  
  78. |> >viewing JPEG's (as part of the OS - without de-compressing) 
  79. |> 
  80. |> Accuse me of pushing technicalities here, but the JPEG still needs to be
  81. |> decrompressed, albeit by hardware(?). A cool thing, for sure, but ultimately
  82. |> how useful? My P75 running FreeBSD decompresses a 640x512 JPEG in 0.8 seconds.
  83.  
  84. During that 0.8 seconds - does the machine multitask?
  85.  
  86. If so - why?
  87.  
  88. |> >without things grinding 
  89. |> 
  90. |> Why should things grind when there are only two tasks desiring CPU use at
  91. |> one time, one of which is a printer spooler?
  92.  
  93. You could be using them all!
  94.  
  95. You could be copying/compressing files etc in the command shell, while doing a
  96. drag & drop OLE from your Vector drawing (or JPEG decompressor) into the DTP
  97. program...
  98.  
  99. |> >(and all in 24 bit colour....)
  100. |> 
  101. |> Yes, this is good. I *did* say they were nice machines though ;-)
  102.  
  103. To be honest - the 1024*768 in 32K colours looks nicer...
  104.  
  105. |> >Admittedly - the OS has lacked development recently, but there is a new version
  106. |> >coming out soon, 
  107. |> 
  108. |> Hopefully with proper multitasking. I think part of the problem with people
  109. |> who claim that you don't need pre-emptive MT is that they have never really
  110. |> used it before. Once you have used such a system, there is no going back. 
  111.  
  112. Untrue!
  113.  
  114. I use SGI's in the university with X windows. They have more power than my Risc
  115. PC, but in general use they run slower, because background tasks are taking
  116. time from my foreground ones. Admittedly, ithas to be pre-emptive for it to be
  117. a multi-access system, but I'm talking about what it's like sitting at one,
  118. disregarding other people...
  119.  
  120. |> >together with new processor cards which should deliver up to
  121. |> >260 MIPS. That's faster than the fastest PC (and the fastest Amiga)...
  122. |> 
  123. |> Is this the StrongARM chip? If so, then that is very good. Get a decent OS
  124. |> and you should be flying. NetBSD + StrongARM would be a formidable combination.
  125.  
  126. It is the StrongARM chip...
  127.  
  128. Joe
  129. -- 
  130.  ___
  131. (_|           Maintainer of http://www.tardis.ed.ac.uk/~joe/arc.html
  132.  _|)                          Acorn games homepage
  133. (_|\
  134.